home *** CD-ROM | disk | FTP | other *** search
/ Suzy B Software 2 / Suzy B Software CD-ROM 2 (1994).iso / bootup / boot_a2m / accsel / accsel.txt < prev    next >
Encoding:
Text File  |  1995-05-02  |  6.8 KB  |  128 lines

  1. ------------------------------------------------------------------------------
  2.                   Desk Accessory Selector - by Les Kneeling
  3. ------------------------------------------------------------------------------
  4.  
  5. Why use a selector?
  6. -------------------
  7.      At first sight the amount of memory in an Atari ST appears to be 
  8. enormous. There is, however, a fundamental law of computing which says that 
  9. code will expand to fill the memory available and the last five years have 
  10. confirmed this with the ST. Nowadays programs such as Degas Elite and 
  11. Timeworks use up a megabyte of memory with the addition of a few fonts. Others 
  12. like Calamus and Harlekin need a minimum of a megabyte to get going. Really 
  13. anti-social programs like Signum leave enough space for the accessories but do 
  14. not allow them to be called up.
  15.  
  16.      Until recently desk accessory selectors were written to get around the 
  17. limit of six applied by the desktop. Now the amount of memory available in the 
  18. computer is often the limit. 
  19.    
  20. How does it work?
  21. -----------------
  22.      When the ST is switched on it goes through a number of stages of 
  23. initialisation. It starts up the operating system, checks to see if there is a 
  24. hard disk, runs programs in the AUTO folder, loads the desktop.inf file, runs 
  25. GDOS, and loads desk accessories. The fact that it deals with the programs in 
  26. the AUTO folder before the desk accessories means that an automatically run 
  27. program can be used to control which ones are loaded.
  28.  
  29.      The computer assumes that a file in the root directory of the boot disk 
  30. (or drive C if a hard disk is used) with a '.ACC' extension is an accessory, 
  31. anything else is not. The crude, but effective, method used by every selector 
  32. that I have seen is to rename unwanted accessories with a '.ACX' extension. 
  33. This means that when the AUTO programs have run their course and the operating 
  34. system loads the accessories, the '.ACC' ones will be loaded and the '.ACX' 
  35. ones will not.
  36.  
  37. The AUTO folder
  38. ---------------
  39.      There are a few things to bear in mind when using the AUTO folder. 
  40.      First, the programs must have a '.PRG' extension even though they do not 
  41. use GEM. The normal convention is that programs which do not use GEM have the 
  42. TOS extension.
  43.  
  44.      Second, the order in which the programs execute is the order in which 
  45. they appear in the directory. The desktop always sorts the directory listing 
  46. in some way and cannot be used to predict which AUTO program will be run 
  47. first. There are two ways around this problem. There are a number of programs 
  48. in the Public Domain which will list the directory without sorting (DosAcc, my 
  49. PD accessory has this facility and is available from the ST Club). The 
  50. alternative is to create the AUTO folder from scratch and copy the programs 
  51. into it in the required order of execution. Some experimentation may be needed 
  52. to get things in the right order but most AUTO programs have come with some 
  53. guidance. The exception is the hard disk patch AHDI - which must come first.
  54.  
  55.      Third, there is a little quirk in the operating system which crashes the 
  56. computer after the AUTO programs have run and before the desk accessories 
  57. load. Jeremy Hughes, of Fontkit fame, believes that the number of AUTO 
  58. programs is the cause and recommends that a 'do nothing' program is included 
  59. in the AUTO folder to fix this if it occurs. I think that the system crashes 
  60. in a rather more random way than this but I admit that I have not researched 
  61. it in any way.
  62.  
  63. The Listing
  64. -----------
  65.  
  66.      That is the background to the program, now to the details. The listing is 
  67. very fully commented but there are a couple of points which are worth talking 
  68. about.
  69.  
  70.      AUTO programs run at a stage in the initialisation process where there 
  71. are only two graphics resolutions - low and high. If the desktop.inf says that 
  72. the computer should start in medium resolution this happens after the AUTO 
  73. programs have finished executing. The first thing that the program does is to 
  74. find out whether it is running in colour or mono and sets a flag. According to 
  75. the state of the flag a two or four column display is produced.
  76.  
  77.      The program reads the root directory twice. First to find all of the 
  78. files with a '.ACC' extension, and second to find the files with a '.ACX' 
  79. extension.
  80.  
  81.      The filenames are added to a linked list. Each time a filename is read 
  82. malloc is called to reserve a new chunk of memory big enough to hold a struct 
  83. which consists of a string to hold the filename and pointers to the previous 
  84. and next entries in the list. Using the pointers the program can move back and 
  85. forward through the list as required.
  86.  
  87.      The list is displayed on the screen and a call to Bconin() waits for 
  88. keystrokes which are then fed to a switch-case statement for interpretation. 
  89. This is a little more complex than it appears because Bconin() returns a long 
  90. and the switch will only accept an int. It is possible to ignore this 
  91. difference because the 'normal' keyboard characters are returned in the low 
  92. word. On the other hand the cursor keys and other 'special' keys are returned 
  93. in the high word. I used a union to get around the problem - it is treated as 
  94. a long for the call to Bconin() and is split into key.split.lowword and 
  95. key.split.highword so that it can be fed to the case statements.
  96.  
  97.      The last section of the listing is a group of procedures to make the 
  98. screen handling more readable. Most of them are self explanatory, but perhaps 
  99. auto_overflow_off() needs some explanation.
  100.  
  101.      When the screen is being used as if it was a character device (the VT52 
  102. emulator), writing a character to the last character space on the last line of 
  103. the screen will cause the screen to scroll. I wanted the menus on the bottom 
  104. of the screen to go right into the corner so I called auto_overflow_off() 
  105. before displaying them. This disables the trigger for the scroll and keeps the 
  106. screen tidy. It is important to return the VT52 to normal - just in case.
  107.  
  108. Finally
  109. -------
  110.  
  111.      The program was written to be extendable. In fact the facility to 'Clear 
  112. all accessories' was 'bolted on' after the program was finished. Other 
  113. extensions can be added simply by adding cases to the switch statements. 
  114. Although it was written in Laser C it should work with any other K&R 
  115. specification compiler.
  116.  
  117. Bolt-on number 2
  118. ----------------
  119.  
  120.      To accomodate programs that allow accessories to be loaded from 
  121. directories other than the root, I have added a configuration file to ACCSEL. 
  122. To change the directory type c then enter the full path for the directory, say 
  123. C:\accs and hit return. The display updates to show the accessory list. To save 
  124. the configuration file type w. A file called ACCPATH is created in the root 
  125. directory. This will be read next time the program is used and that directory 
  126. will be set as the default.
  127.  
  128.